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1 .  This  tailoring  document  defines  the  Government’s  requirements  and  expectations  for 
contractor  performance  in  defense  system  acquisitions  and  technology  developments. 

2.  This  revised  SMC  tailoring  comprises  the  text  of  The  Aerospace  Corporation  report 
number  TOR-20 15-0 1949-Rev  A,  entitled  Tailoring  of  IEEE  15288.1:  Specialty  and  Systems 
Engineering  Supplement,  dated  July  28,  2017.  The  major  changes  in  this  release  are  documented 
in  the  Change  Log  contained  in  this  document. 

3.  Beneficial  comments  (recommendations,  changes,  additions,  deletions,  etc.)  and  any 
pertinent  data  that  may  be  of  use  in  improving  this  document  should  be  forwarded  to  the 
following  addressee  using  the  Standardization  Document  Improvement  Proposal  appearing  at  the 
end  of  this  document  or  by  letter: 
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Document  Change  Record 


Document  Number  Change  Rationale 


TOR-20 15-0 1949 

also  published  as 

SMC-T-006  (2015) 

Transferred  specialty 
engineering  requirements  from 
SMC-S-001  (2013)  not  included 
in  IEEE  15288.1 

Effective  specialty  engineering  planning 
is  critical  to  high-reliability  space 
systems  for  optimizing  total  system 
performance  and  total  ownership  costs, 
while  ensuring  that  the  system  is 
designed,  operated,  and  maintained  to 
effectively  provide  the  user  with  the 
ability  to  complete  their  mission. 

TOR-20 15 -01 949-REV  A 
(this  document) 

also  published  as 

SMC-T-006  (2017) 

( 1 )  Changed  title  from 
“Specialty  Engineering 
Supplement. . .”  to 
“Specialty  and  Systems 
Engineering  Supplement...” 

(2)  Added  Document  Change 
Record 

(3)  Updated  Section  2,  Context 

(4)  Added  Section  3.2.17, 
Balanced  Assessment  - 
Cost,  Schedule,  Risk,  and 
Technical  Performance 

(5)  Added  Section  3.2.18, 
Mission  Critical  Fault 
Analysis  (MCFA) 

(6)  Added  Section  3.2.19, 
Operationally  Relevant 
Testing 

(7)  Added  Section  3.2.20, 

Space  System  Verification 

(1)  Expands  scope  to  accommodate 
space-specific  generic  systems 
engineering  tailoring 

(2)  Provides  document  history 

(3)  Documented  current  status  of 
documents  and  added  reference  to 
adoption  notices. 

(4)  Addendum  requirements  clarifying 
the  balancing  of  system 
effectiveness  and  cost  assessments 

(5)  Transferred  definition,  output 
requirements  and  output  attributes 
formerly  in  SMC-S-001  to  establish 
requirements  to  conduct  MCFA  to 
supplement  mission-FMECA 
requirements  for  space  systems  and 
aligned  SMC  systems  engineering 
process  names  with  15288. 

(6)  Transferred  definition,  output 
requirements,  output  attributes 
formerly  in  SMC-S-001  to 
supplement  end-to-end  system 
testing  requirements  for  space 
systems.  Updated  terminology  from 
Test  Like  You  Fly  (TLYF)  and  Like 
You  Fly  (LYF)  to  Operationally 
Relevant  Testing  in  accordance  with 
AF1  63-119.  Transferred  and 
updated  applicable  documents. 

(7)  Supplements  general  verification 
requirements  with  a  space-specific 
recommended  practice. 

(8)  Added  Section  3.2.21, 
Systems  Engineering  Data 
Item  Descriptions  (DIDs) 

(9)  Editorial  cleanup  with  no 
change  of  intent  or 
requirements 


(8)  Provides  DOD-required  output 
attributes  for  contractors  systems 
engineering  planning 

(9)  Various  tense  updates  (present  to 
past)  and  addition  of  synonyms  in 
Logistics  to  reflect  changes  from 
20 1 5  to  present. 
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Tailoring  of  IEEE  15288.1: 

Specialty  and  Systems  Engineering  Supplement. 

1 .  Intent  of  this  Tailoring  Document 

This  tailoring  document  is  a  domain-area  supplement  to  the  industry-consensus  systems  engineering 
standard,  adding  specialty  engineering  requirements  that  have  been  historically  deemed  valuable  to 
mission  assurance/success  of  high-reliability  space  systems. 

The  specialty  engineering  tailoring  in  this  document  supplements  IEEE  15288.1-2014  Annex  E,  which 
extends  the  guidance  of  1SO/1EC/1EEE  15288:2105  Annex  E.4,  Process  view  for  specialty  engineering. 
This  document  identifies  the  specialty  engineering  disciplines1,2  which  are  critical  to  high-reliability  space 
systems  for  optimizing  total  system  performance  and  total  ownership  costs,  while  ensuring  that  the 
system  is  designed,  operated,  and  maintained  to  effectively  provide  the  user  with  the  ability  to  complete 
their  mission. 

The  systems  engineering  tailoring  provides  additional  detail  in  areas  where  IEEE  15288.1  provides  high 
level  requirements  or  notes,  but  where  more  detailed  requirements  are  believed  necessary  to  maintain  the 
level  or  rigor  required  by  national  security  space  acquisitions. 

2.  Context 

IEEE-15288. 1:  2014,  Standard  for  Application  of  Systems  Engineering  on  Defense  Programs 

IEEE  15288.1  is  an  addendum  to  1SO/1EC/1EE- 15288  for  application  of  systems  engineering  on  defense 
programs  that  was  developed  by  a  joint  services  working  group  under  the  auspices  of  the  Defense 
Standardization  Council.  This  document  invokes  the  DOD-adopted  systems  engineering  process  in 
1SO/1EC/1EEE-15288:  2015,  Systems  and  Software  Engineering  —  System  life  cycle  processes 3  and 
expands  the  process  outcomes  and  outputs.  The  Joint  DOD  Systems  Engineering  working  group  was  led 
by  industry  and  the  SMC  Chief  Systems  Engineer  on  behalf  of  DOD.  This  systems  engineering  standard 
was  developed  in  conjunction  with  IEEE  15288.2,  Technical  Reviews  and  Audits  on  Defense  Programs, 
and  coordinated  with  SAE  International’s  EIA-649-1,  Configuration  Management  for  Defense  Programs. 
IEEE  15288.1  was  formalized  as  a  standard  by  the  IEEE’s  Computer  Society.  The  balloting  involved  a 
broad  range  of  government  and  industry  members  and  was  nearly  unanimous.  IEEE  15288. 1  has  been 
adopted  by  DOD  for  use  on  contracts1 2 3 4  and  was  included  in  the  SMC  Compliance  Standards  list  on 
November  13,  2015. 

SMC-S-001  (2013),  Systems  Engineering  Products  and  Requirements 

SMC-S-001  was  the  systems  engineering  standard  that  was  used  by  SMC  between  2008  and  2015.  It  was 
used  as  the  basis  for  development  of  IEEE  15288.1  since,  at  that  time,  it  was  the  only  systems  engineering 
standard  found  to  be  suitable  for  use  on  DOD  contracts.  This  standard  was  the  only  systems  engineering 
standard  that  integrates  systems  and  specialty  engineering  as  it  relates  to  high-reliability  space  systems  in 


1  SMC  Standard  #  SMC-S-001  (2013),  Systems  Engineering,  Section  4.3;  a  republication  of  The  Aerospace  Corporation  report  # 
TR-20 13-00001,  Systems  Engineering  Requirements  and  Products. 

2  USAF  Space  and  Missile  Systems  Center.  SMC  Systems  Engineering.  Specialty  Engineering  Disciplines.  Volume  2,  1st  edition. 

3  October  2011. 

3  Notice  -  ISO/IEC/IEEE  15288  Adoption,  Tier  1.  http://quicksearch.dla.mil/qsDocDetails.aspx7ident_numberfl3120 

4  Notice  -  IEEE  15288.1  Adoption,  Tier  1.  http://quicksearch.dla.mil/qsDocDetails.aspx7ident_numberf80941 
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a  contractually  compliant  manner.  The  specialty  engineering  requirements  in  this  document  derive, 
verbatim,  from  SMC-S-001.  SMC-S-001  has  been  superseded  in  the  SMC  Compliance  Standards  list  by 
IEEE  15288.1,  and  this  supplement. 


3.  Tailoring  of  IEEE  15288.1 

3.1.  General  IEEE  15288.1  Tailoring  Instructions 

The  requirements  in  this  document  shall  be  used  in  conjunction  with  IEEE  15288.1  on  contract. 

The  requirements  of  this  document  shall  prevail  in  the  event  of  conflict  between  this  document  and 
IEEE  15288.1. 

Annex  E.4  from  1SO/1EC/1EEE-15288:2015  shall  be  normative  (requirements)  rather  than 
informative  (guidance). 

Sections  3.2.1  through  3.2.16  of  this  document  replaces  IEEE  15288.1-2014  Annex  E  in  its  entirety 
and  shall  be: 

1 .  Normative  (requirements  rather  than  informative  guidance), 

2.  Tailored  appropriately  for  specific  acquisition/contract  considerations,  and 

3.  Implemented  as  part  of  the  performance  of  IEEE  15288.1  Task  6.4.1. 3,  Business  or  Mission 
Analysis  Process 

NOTE:  Acquirers  should  utilize  their  organizational  or  domain  area  compliance  standards  list  (or 
other  related  sources)  and  invoke  the  appropriate  standards  for  the  performance  of  detailed 
specialty  engineering  activities. 

Mission  Critical  Fault  Analysis,  (MCFA),  section  3.2.17  of  this  document  shall  be  an  extension  of 
IEEE  15288.1  clauses  6.4.6.4c,  Failure  Mode,  Effects,  and  Criticality  analysis  (FMECA)  and  6.4.9, 
Verification  outputs.  Operationally  Relevant  Testing5  (formerly  known  as  Test  Like  You  Fly  - 
TLYF),  Section  3.2.18  of  this  document  shall  be  an  elaboration  of  IEEE  15288.1  clause  6.4.8. 4, 
Integration  outputs  and  6.4.1 1.4,  Validation  process  outputs. 

Verification  of  Space  Systems,  Section  3.2. 19  of  this  document,  shall  be  an  elaboration  of  IEEE 

15288.1  clause  6.4.9,  Verification. 

3.2.  Specific  IEEE  15288.1  Tailoring  Language 

3.2.1  Specialty  Engineering  Analysis  and  Control 

The  contractor  shall,  for  each  specialty  area  listed  below: 

a.  Ensure  that  the  following  specialty  functions  and  disciplines  are  incorporated  into  the  systems 
engineering  process. 

b.  Establish  a  documented  valid/approved  process  (including  but  not  limited  to  applicable 
corporate  process,  military  standards,  military  handbooks,  NSS/industry  standard  processes) 


5  Air  Force  Manual  number  AFMAN  63-119,  Certification  of  System  Readiness  for  Dedicated  Operational  Testing.  19  February 
2016 
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that  is  comprehensive  and  responsive  to  the  system/end-user  requirements  for  each  specialty 
engineering  area  being  integrated  into  the  systems  engineering  effort. 

c.  Include  specialty  engineering  requirements  in  the  requirements  analysis,  functional 
analysis/allocation,  synthesis,  and  systems  analysis  and  control. 

d.  Include  their  impact  in  system  life  cycle  cost  estimates  as  well  as  in  total  system 
performance/reliability  assessments. 

e.  Document  specific  specialty  engineering  products/outputs  in  the  SEMP. 

3.2.2  Parts,  Materials,  and  Processes  (PMP) 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Detailed  environmental  parameters  are  de fined/ derived  that  impact  parts  performance. 

b.  Parts/materials  engineering/design  requirements  are  allocated,  baselined,  and  traced  to 
system-level  performance  requirements,  including  risk  assessments. 

c.  Functional  parameters  are  baselined  and  captured  in  detailed  technical /  procurement 
specifications. 

d.  Technology  development  plans  are  executed  and  technology  readiness  levels  demonstrate 
products/technology  suitable  for  system  application  and  support  program  development 
schedules. 

e.  Qualified  sources  of  supply  and  industrial  base  assessment  are  addressed. 

f.  Space  systems  radiation-hardening  design  solutions  are  established. 

3.2.3  Structures 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Detailed  performance  and  technical  requirements  for  each  structural  system,  subsystem,  and 
component  are  defined,  allocated,  and  traced  to  system  requirements. 

b.  Structural  design  specifications  comply  with  requirements  and  NSS  industry  practice. 

c.  Verification  methods  for  each  structural  requirement  are  defined. 

d.  Structural  requirements  correlation  with  military  and  other  government  documents,  including 
standards,  specifications,  handbooks,  guidelines,  and  Commander’s  policies,  are  presented. 

e.  Technical  risk  mitigation  approaches  are  defined. 

f.  Trade  studies  and  detailed  analyses  support  structural  design  solutions. 

g.  Analysis  tools  and  techniques  are  consistent  with  NSS  industry  practice. 
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h.  Design  qualification  methods  adequately  define  approach  to  demonstrate  structural  adequacy. 

i.  Quality  assurance  methodology  ensures  delivery  of  high-quality  product. 

3.2.4  Manufacturing 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Producibility  engineering  principles  and  practices  are  integrated  into  the  design  process. 

b.  Manufacturing  methods  and  processes  required  to  build  the  design  are  qualified  and 
demonstrated  to  meet  system  performance  requirements  and  reliability. 

c.  Manufacturing  analyses  include  producibility  analyses  and  manufacturing  and  production 
inputs  to  system  effectiveness,  tradeoff  studies,  and  life  cycle  cost  analyses. 

d.  Alternative  designs  and  capabilities  of  manufacturing  are  evaluated. 

e.  Long-lead-time  items,  material  source  limitations,  availability  of  materials  and  manufacturing 
resources,  and  production  cost  are  identified,  assessed,  and  documented. 

f.  Manufacturing-critical  characteristics  of  people,  product,  and  process  solutions  and  their  risks 
are  identified. 

g.  Tooling  and  test  equipment  strategies  and  requirements  are  defined. 

h.  Manufacturing  and  producibility  requirements  and  constraints  are  defined. 

i.  Items  are  producible  and  stable  manufacturing  processes  are  in  place  to  reduce  risk, 
manufacturing  cost,  lead  time,  and  cycle  time,  and  to  minimize  use  of  strategic  and  critical 
materials. 

j.  As  part  of  system  design,  manufacturing  methods,  processes,  and  process  controls  have  been 
defined,  evaluated,  and  selected,  based  on  total  system  cost,  schedule,  performance,  and  risk. 

k.  Product  design  has  stabilized,  the  manufacturing  processes  and  process  controls  have  been 
proven,  and  production  facilities,  equipment,  capability,  and  capacity  are  in  place  (or  are 
about  to  be  established)  to  support  the  approved  schedule. 

3.2.5  Quality  Assurance 

NOTE:  Comprehensively  addressed  as  part  of: 

•  Quality  Management  Process  -  6.2.5  and 
Quality  Assurance  process  -  6.3.8 

3.2.6  Test 

NOTE:  Comprehensively  addressed  as  part  of: 

•  Project  Assessment  and  Control  -  6. 3. 2. 3  (process)  and  6. 3.2. 4  (outputs); 

•  Decision  Management  Process  Outputs  -  6. 3. 3. 4; 

•  Risk  Management  Process  -  6.3.4; 
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•  Configuration  management  -  6. 3. 5.4  c.2  (process)  and  6. 3. 7. 4  c.l  (outputs); 

•  Measurement  -  6.3.7. 1  (process)  and  6. 3. 7.4  c.  1  (outputs); 

•  System  Requirements  Definition  process  -  6.4.3.4; 

•  Architecture  Definition  Process  -  6.4.4. 1 ; 

•  Design  Definition  Process  -  6.4.5. 1 ; 

•  Integration  Process  Outputs  -  6.4.8.4 

•  Verification  Process  Output  -  6. 4.9. 4; 

•  Transition  Process  Output  -6.4.10.4; 

•  Operation  Process  Output  -  6.4. 12.4;  and 

•  Data  Requirements  -  5.3 

3.2.7  Survivability 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  System-level  survivability  requirements  are  defined,  allocated,  baselined,  and  traced  to  the 
system-level  requirements. 

b.  System  survivability  attributes  and  mission  objectives  evolved  into  a  set  of  system-level 
survivability  requirements. 

c.  An  approach  for  verification  of  system-level  survivability/operability  requirements  is 
identified. 

d.  Test  facilities  capable  of  simulating  threat  environments  are  identified. 

e.  Threat  assessments  and  analysis  are  conducted,  defining  categories  of  the  expected  threats 
(i.e.,  nuclear,  biological,  terrorism,  etc.)  and  their  likelihood  of  occurrence. 

f.  Threats  and  mitigation  strategies  are  defined. 

g.  Nuclear  and  other  threats  are  translated  into  system  environments  and  modeled. 

h.  System/threat  interaction  analysis  is  performed. 

i.  Hardness  levels  and  definition  of  hardness  margins  and  design  criteria  are  identified. 

3.2.8  Environmental,  Safety,  and  Occupational  Health  (ESOH) 

NOTE:  address  as  part  of  Systems  Analysis  Outputs  -  6. 4.6. 4 

a.  System-level  ESOH  requirements  are  defined,  allocated,  baselined,  and  traced  to  the  system- 
level  requirements: 

( 1 )  Hazards  are  identified. 

( 1 )  Hazardous  materials  are  analyzed,  including  handling  and  disposal. 

(2)  Mitigation  decisions  are  evaluated. 

(3)  Residual  risk  acceptance  is  evaluated. 
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(4)  Current  mitigation  efforts  are  assessed. 


(5)  National  Environmental  Policy  Act  (NEPA)  and  Programmatic  Environmental,  Safety, 
and  Elealth  Evaluation  (PESHE)  requirements  are  incorporated. 

b.  ESOH  risks  and  corrective  actions  and  alternatives  are  developed  to  eliminate  or  reduce 
environmental,  health,  and  identified  hazards  and  unsafe  conditions;  and  the  threat  of 
regulatory  violations  is  identified. 

c.  Criteria  are  established  for  monitoring  and  reporting  of  pollution  elimination/reduction 
efforts. 

d.  A  containment  program  is  developed,  including  procedures  for  safe  use  and  disposal. 

e.  Elandling  and  disposal  of  hazardous  material  are  included  in  life  cycle  cost  estimates. 

3.2.9  Contamination 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Requirements  for  contamination  control  are  identified  for  sensitive  components  or 
subsystems,  including: 

(1)  Need  for  normal,  medium,  or  challenging/stressing  contamination  control  to  meet 
requirements. 

(2)  Any  needs  for  new  or  upgraded  facilities. 

(3)  Shipping  and  prelaunch  operations. 

b.  Cleanliness  challenges  are  identified  and  solutions  proposed,  including: 

(1)  Uncleanable  materials. 

(2)  Solvent  incompatibility. 

(3)  Mission-unique  requirements  to  launch  vehicle. 

(4)  Eligh  outgassing  materials. 

c.  Eleritage  analysis  comprehensively  and  completely  demonstrates  that  prelaunch  cleanliness 
requirements  can  be  met  and  that  overall  end-of-life  (EOL)  requirements  can  be  met. 

3.2.10  Mass  Properties 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Mass  properties  requirements  are  reviewed  and  generated;  changes  are  proposed  where 
applicable. 

b.  Baselined  design  is  reflected  in  the  mass  properties  analyses  and  reports. 
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c. 


Subsystem  and  subcontractor’s  definition  of  critical  mass  properties  parameters  are  reviewed 
and  tracked  to  ensure  that  specification  requirements  are  met. 


d.  Configuration  layout  for  optimizing  mass  properties  (weight,  balance,  and  inertia)  is 
analyzed. 

e.  Balance  weight  locations  are  defined.  Provisions  for  balance  weight  installation  are  ensured. 

f.  Test  plan  and  test  procedure  are  generated;  method  of  verifying  requirements  is  defined; 
required  mechanical  ground  support  equipment  (MGSE)  is  identified. 

3.2.11  Logistics/Integrated  Logistics  Support 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Logistics  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements. 
Logistics  management  information  (LMl),  life  cycle  cost  (LCC)  analysis  with  a  discussion  of 
risks,  and  any  risk  reduction  or  control  are  included  for  the  following  logistics  areas/lLS 
elements: 

(1)  Design  interface  -  system  reliability,  maintainability,  availability,  survivability, 
including  hardness  and  unique  characteristics. 

(2)  Support  concepts/maintenance  plan  -  initial  and  steady-state  support;  implementation 
and  transition  schedule  at  organizational  and  depot  level;  warranties  and  SORAP/Depot 
Source  of  Repair  (DSOR). 

(3)  Manpower  and  personnel  -  operations,  maintenance  (hardware  and  software),  and 
training  support  personnel. 

(4)  Supply  support  -  support  concept  for  initial  and  steady  state,  sparing/provisioning 
requirements  to  support  concept  of  operation. 

(5)  Support  equipment  and  simulators  -  common  and  specialized/peculiar  organizational 
and  depot  support  equipment,  and  system-level  simulators  and  trainers. 

(6)  Training  systems  and  training  support  -  initial  and  follow-on  training,  equipment, 
documentation  and  facilities;  student  requirements. 

(7)  Technical  data  -  engineering  drawings  and  technical  orders;  data  rights,  technical 
manual  contract/delivery  requirements. 

(8)  Computer  resource  support  -  software  and  database  maintenance,  facilities,  equipment, 
COTS,  and  documentation. 

(9)  Facilities  -  Space  projections,  new  or  reuse  requirements,  site  survey,  deployment,  and 
transportable  facilities. 

( 1 0)  Packaging,  handling,  storage  and  transportation  (PHS&T)  -  LMl  packaging  analysis, 
government  and  commercial  packaging  requirements,  and  packing  requirements  meet 
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all  concept  of  operations,  including  deployment  storage,  oversized  and  special 
packaging  instruction,  and  air,  ground,  or  sea  shipping  requirements. 

3.2.12  Human  Systems  Integration  (HSI) 

NOTE  1:  Address  as  part  of  Project  Planning  Outputs  -  6.3. 1.4 

NOTE  2:  This  section  presents  requirements  for  the  systems  engineering  planning  activities 
associated  with  human  systems  integration.  The  requirements  for  the  subordinate  domains  are 
contained  within  specific  domain-level  standards. 

3.2.12.1  Scope  and  Nature  of  Work 

a.  Human  systems  integration  (HSI)  shall  be  applied  as  part  of  the  overall  systems  engineering 
effort  to  efficiently  and  effectively  integrate  humans  into  the  design  of  the  system.  The  goals 
of  the  human  systems  integration  effort  shall  be  to: 

(1)  Plan  and  execute  efficient  development  of  systems  that  effectively  integrates  human 
operators,  maintainers,  support  personnel,  and/or  users. 

(2)  Plan  for  impacts  of  military  system  operation,  use,  or  disposal  on  potentially  affected 
general  populations. 

(3)  Ensure  system  performance  by  ensuring  human  integration  and  specified  levels  of 
performance. 

(4)  Apply  to  all  aspects  of  military  systems,  equipment,  and  facilities  acquisition,  including 
analysis,  design,  development,  acquisition,  test  and  evaluation,  sustainment,  and  product 
improvement. 

(5)  Implement  by  making  effective  demands  upon,  and  tradeoffs  between,  personnel 
resources,  skills,  and  training  to  allow  for  knowledgeable  management  of  total  system 
ownership  costs. 

3.2.12.2  HSI  Planning 

a.  HSI  shall  be  part  of  the  overall  systems  engineering  effort  within  the  total  project  and  shall 
coordinate  with  all  appropriate  systems  engineering  specialties  or  disciplines.6 

b.  HSI  planning  shall  establish  the  collaboration  between  HSI  domain  disciplines  with  emphasis 
on  each  domain  area’s  participation  in  system  (hardware  and  software)  design  and  testing. 

c.  HSI  shall  be  documented  and  managed  accordingly. 

d.  Risk  management  —  HSI-related  risks  and  issues  that  involve  technical,  cost,  or  schedule 
risks  shall  be  identified  and  managed  as  early  as  possible  as  part  of  a  program’s  overall  risk 
management  approach. 


6  Support  material  for  HSI  planning  can  be  found  in  The  Aerospace  Corporation  report  TOR-2012(8960)-1  REV  A  -  HSI  Planning 
Requirements. 
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e.  Reviews  —  HSI-related  activities  shall  be  reported  in  all  appropriate  programmatic  or 
technical  reviews. 

f.  HS1  shall  address  the  following  discipline  areas7: 

( 1 )  Manpower  -  number  and  mix  (military,  contractor,  and  civilian)  of  personnel  required, 
authorized,  and  available  to  train,  operate,  maintain,  and  support  the  system. 

(2)  Personnel  -  human  aptitudes,  skills,  experience  levels,  and  abilities  required  to  operate, 
maintain,  and  support  the  system  when  fielded  and  throughout  its  life  cycle. 

(3)  Training  -  instruction  and  resources  required  to  provide  the  necessary  knowledge,  skills, 
and  abilities  to  properly  integrate,  operate,  maintain,  and  support  the  system. 

(4)  Human  factors  engineering  -  integration  of  human  capabilities  (cognitive,  physical, 
sensory,  and  team  dynamics)  into  system  design,  development,  modification,  and 
evaluation  to  optimize  human-machine  interactive  performance  for  operation  and 
maintenance  of  the  system. 

(5)  Environment  -  issues  related  to  water,  air,  and  land  and  the  interrelationships  between 
these  and  all  living  things. 

(6)  Safety  -  issues  including  design  of  operational  systems  to  minimize  the  possibilities  for 
accidents  or  mishaps  that  threaten  personnel  or  the  survival  of  the  system. 

(7)  Occupational  health  -  minimizing  risk  of  injury,  acute  and/or  chronic  illness,  disability, 
and/or  reduced  job  performance  to  personnel  who  operate,  maintain,  or  support  the 
system. 

(8)  Survivability  -  minimizing  risk  of  fratricide,  detection,  and  probability  of  being  attacked; 
and  inclusion  of  factors  that  enable  the  crew  to  withstand  man-made  or  natural  hostile 
environments  without  aborting  mission  or  suffering  acute/chronic  illness  or  death. 

(9)  Habitability  -  living  or  working  conditions  necessary  to  sustain  the  morale,  safety,  health, 
and  comfort  of  the  user/maintainer  population,  contributing  directly  to  personnel 
effectiveness  and  mission  accomplishment. 

g.  The  HS1  activities  shall  be  integrated  into  the  overall  systems  engineering  program  and 
management.  The  HS1  requirements  specified  herein  shall  be  coordinated  with,  but  shall  not 
duplicate,  efforts  performed  to  fulfill  other  contractual  program  tasks.  The  HSI-related 
portion  of  any  analysis,  design,  or  test  and  evaluation  program  shall  be  conducted  under  the 
direct  cognizance  of  a  qualified  HSl-domain  practitioner(s)  assigned  such  responsibility  by 
the  contractor.  “Qualified”  should  consider  basis  of  education,  experience,  and/or 
certification  in  systems  engineering,  human  systems  integration,  or  any  of  the  individual  HS1 
domains. 


7  Individual  DOD  services/components  may  organize  these  same  domain  areas  into  different  domain  area  combinations. 
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h.  The  contractor  shall  determine  the  scope  and  nature  of  HS1  domain  area  applicability  such 
that: 

(1)  Program/contract  requirements  are  allocated  to  the  appropriate  HS1  domain  (discipline) 
areas. 

(2)  Responsible  entities  (e.g.,  HS1  Working  Group  and/or  Integrated  or  Cross  Product  Teams  - 
IPTs)  are  identified  for  each  applicable  HS1  domain  within  the  systems  engineering  1PT 
structure. 

(3)  Key  or  lead  HS1  personnel  in  all  applicable  domains  are  identified  and  described  in  terms 
of  qualifications. 

(4)  Interfaces  between  related  HS1  domains  are  defined  and  developed  to  ensure 
comprehensive  and  effective  execution  of  human-related  requirements. 

(5)  Interfaces  are  established  between  the  prime  contractor  and  all  subcontract  or  vendor  HS1 
activities. 

(6)  Domain  interdependencies  and  tradeoffs  are  identified  to  ensure  humans  are  considered  as 
part  of  system  design  on  par  with  the  hardware  and  software. 

i.  HS1  planning  shall  be  described  in  a  configuration-managed  document  that  is  used  to  execute 
the  HS1  effort. 

j.  HS1  planning  shall: 

(1)  Include  the  human-related  tasks  to  be  performed,  milestones,  level  of  effort,  methods,  and 
design  concepts  to  be  used,  and  the  test  and  applicable  evaluation  methodologies. 

(2)  Describe  data  flow  between  HS1  domains  and/or  IPTs  (see  Appendix  B  Giver-Receiver 
relationships). 

(3)  Be  documented  as  a  human  systems  integration  plan  and/or  within  the  Systems 
Engineering  Management  Plan  (SEMP). 

(4)  Be  validated/updated  prior  to  major  programmatic  and  technical  reviews. 

(5)  Be  updated  at  program  rebaseline  and/or  engineering  change  proposal  (ECP). 

k.  The  following  activities  shall  be  considered: 

( 1 )  Integration  of  relevant  human-related  data  and  analyses  into  all  design  and  development 
activities  with  human-related  requirements,  design  features,  or  implications,  especially 
considering  the  relationships  between  these  efforts  and  opportunities  to  effect  efficiencies 
in  system  development,  operation,  and  maintenance. 

(2)  HS1  implications  for  integrated  development  of  logistics  and  operational  support  materials, 
including  procedures,  manuals,  and  technical  documentation. 

(3)  User  involvement  and  community  review  of  human-related  activities  and  products, 
including  prototype  assessments,  peer  reviews,  and  formal  reviews. 
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(4)  Verification  and/or  validation  of  human  requirements  and  human-related  design 
options/solutions. 

l.  The  contractor  shall  identify  and  manage  human-related  risks,  issues,  and  opportunities  in  a 
way  that: 

(1)  Ensures  HSl-related  risks  are  managed  within  the  program’s  risk  management  process. 

(2)  Identifies  potential  cost,  schedule,  technical,  and  performance  risks  that  result  from 
human  systems  integration. 

(3)  Quantifies  such  risks  and  their  impacts  on  cost,  schedule,  and  performance. 

(4)  Evaluates  and  defines  the  sensitivity  of  HSl-related  risks. 

(5)  Identifies  alternative  solutions  to  HSl-related  issues  and  defines  the  associated  risks  of 
each  alternative. 

(6)  Documents  the  identified  risks,  their  potential  impact,  and  the  mitigation  action(s)  taken. 

(7)  Manages  the  actions  required  to  avoid,  minimize,  control,  or  accept  each  HSl-related  risk. 

m.  Human  systems  integration  domain  activities  shall  be  addressed  in  all  applicable 
programmatic  and  technical  reviews,  including  but  not  limited  to: 

( 1 )  Programmatic  reviews,  which  include  but  are  not  limited  to  program  management 
review,  integrated  baseline  review,  and  integrated  system  review. 

(2)  System  reviews,  which  include,  but  are  not  limited  to: 

i.  Concept  and  requirements  definition. 

ii.  Analysis  of  alternatives. 

iii.  System  requirements  review. 

iv.  System  function  review. 

v.  Preliminary  design  review. 

vi.  Critical  design  review. 

vii.  Test  readiness  reviews. 

viii.  System  safety  reviews. 

ix.  Engineering  change  proposal  reviews. 

x.  Post-implementation  reviews. 

(3)  Subsystem  and  other  lower-level  reviews  including,  where  applicable,  software 
specification,  test  readiness,  and  functional  reviews  (e.g.,  support,  training,  systems 
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engineering,  test,  and  manufacturing). 

3.2.13  System  Security  and  Information  Assurance 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  A  system  security  program  is  implemented  that  includes  Information  Systems  Security 
Engineering  (1SSE). 

b.  Protection  needs  are  documented,  including  identification  of  mission  assets  and  assessment  of 
threats  to  those  assets. 

c.  System  security  requirements  are  defined  and  complete.  Includes  system-specific  threats  and 
compliance  with  applicable  DOD,  national,  and  international  system  security  policies. 

Includes  system  security  design  constraints. 

d.  System  security  architecture  and  management  plan  is  documented. 

e.  Security  design,  including  constraints  and  tradeoffs,  is  detailed;  cryptography  plans  are 
coordinated  with  the  National  Security  Agency. 

f.  Certification  and  accreditation  process  activities  are  coordinated. 

g.  Protection  mechanisms  have  been  verified  to  satisfy  security  requirements  and  residual 
security  risks  have  been  approved  by  the  appropriate  authorities. 

3.2.14  Reliability 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  Space  system-specific  reliability  requirements  are  defined,  allocated,  baselined,  and  traceable 
to  system  requirements. 

(1)  Parameters  and  limits  are  defined  at  this  level  and  provided  within  the  system 
specification. 

(2)  Reliability  requirements  are  reviewed  against  functional  requirements  and  customary 
design  practices. 

b.  Applicable  specific  design  tasks  and  analyses  are  conducted,  including: 

(1)  Failure  Reporting  Analysis,  Corrective  Action  System  (FRACAS). 

(2)  Source  selection  and  vendor  control  procedures. 

(3)  Failure  Modes  Effects  and  Criticality  Analysis  (FMECA). 

(4)  Derating  and  margins  of  safety. 

(5)  Fault  coverage. 

(6)  Single-point  failure. 
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(7)  Redundancy/single  string. 

c.  The  reliability  program  plan  are  developed  for  final  top-level  space  system. 

d.  Items  in  development  that  have  impact  on  support  resources  are  identified,  including  time, 
people,  money,  parts,  tools,  storage,  and  transportation  assets. 

.15  Electromagnetic  Interference  and  Compatibility  (EMI/EMC) 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  EMEEMC  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements, 
including: 

(1)  Use  of  RF  shielded  enclosures  for  vehicle,  subsystems,  or  components,  and  other 
significant  design  features  affecting  EMC. 

(2)  Structure  RF  shielding  effectiveness  in  excess  of  40  dB. 

(3)  Return  of  power  on  spacecraft  structure. 

(4)  Unshielded  or  untwisted  or  unpaired  wires. 

(5)  Radiated  emissions  requirements  less  than  20  dBuV/m. 

(6)  Gimbals  that  form  part  of  a  shielded  enclosure — high  risk. 

(7)  Radiated  susceptibility  requirements  in  excess  of  1 00  V/m — high  risk. 

(8)  Systems  having  passive  intermodulation  products  of  order  7  or  less  in  platform  receiver 
pass  bands. 

(9)  Any  EMC  wire  shields  or  grounds  that  are  required  to  flex  or  rotate  or  rub/roll  more 
than  20  times. 

(10)  Magnetic  dipole  requirements  more  stringent  than  3.5E-3  A-mA2/kg. 

(11)  All  first-flight/first-use  EMC  parts. 

(12)  All  cryo-cooled  sensor  EMC  designs. 

(13)  All  EMC  requirements  with  negative  margin. 

(14)  Any  RF  receiver  required  to  work  in  a  dense  EMI  environment. 

(15)  Any  RF  receiver  with  a  burnout  level  of  less  than  30  dBm  (1  mW). 

b.  A  summary  of  all  significant  areas  are  addressed  in  the  EMC  Control  Plan,  including  but  not 
limited  to  program  requirements  tailoring  and  the  use  of  heritage  equipment  and  other  ND1. 

c.  EMC  requirements  verification  planning  to  the  unit  level  is  conducted. 


d.  EMI/EMC  risk  areas  are  identified  and  risk  mitigation  closure  plans  developed. 

3.2.16  System  Safety 

NOTE:  Address  as  part  of  Project  Planning  Outputs  -  6. 3. 1.4 

a.  System  safety  requirements  are  defined,  allocated,  baselined,  and  traced  to  system 
requirements,  including: 

(1)  System  safety  design  requirements  are  specified  and  safety  design  criteria  determined. 

(2)  Elazards  associated  with  the  system  are  identified  and  risks  involved  identified;  hazard 
analysis  is  complete. 

(3)  Risks  are  minimized  in  the  design,  materials,  testing,  and  production  of  end  item. 

(4)  Retrofit  actions  are  minimized  by  inclusion  of  safety  features  during  definition  and 
development  of  system. 

b.  Elazardous  substances,  components,  and  operations  are  isolated  from  other  activities,  areas, 
personnel,  and  incompatible  materials. 

c.  Catastrophic  risks  are  eliminated. 

d.  Critical  hazards  are  minimized. 


3.2.17  Balanced  Assessment  -  Cost,  Schedule,  Risk,  and  Technical  Performance 

NOTE:  Address  as  part  of  Project  Assessment  and  Control  process  outputs  -  6. 3.2.4 
and  Measurement  process  outputs  -  6.3.7 

a.  Each  assessment  of  system  effectiveness  shall  surface  deficiencies  for  key  performance 
parameters  (KPPs)  and  ensure  that  the  traceability  between  the  MOEs,  MOPs,  KPPs,  and 
TPMs  is  maintained. 

b.  Each  assessment  of  cost  shall: 

(1)  Include  established  design-to-cost  targets,  a  current  estimate  of  these  costs,  and  known 
uncertainties  in  these  costs. 

(2)  Address  cost  and  schedule  risk. 

(3)  Be  conducted  and  updated  as  designated  in  the  contract  to  support  decisions,  assessments 
of  system  cost  effectiveness,  and  tradeoff  studies  to: 

(a)  Identify  the  sunk  costs  to  the  extent  required  for  the  specific  cost  assessment. 

(b)  Provide  an  estimate  of  the  remaining  development,  production,  operations  and  support 
(O&S),  and  life  cycle  costs  for  the  proposed  system  concept  to  include  new  or  modified 
government  facilities. 
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(c)  Demonstrate  that  the  system  concept  and  development  plans  for  completing 
development — including  any  plans  for  new  parts,  materials,  or  processes,  new  or 
modified  facilities,  or  other  new  or  modified  resources — are  affordable  and  meet  the 
program  schedule  requirements  at  acceptable  risk. 

(d)  Identify  the  economic  consequences  of  solution  alternatives. 

3.2.18  Mission  Critical  Fault  Analysis 

Definitions  - 

Critical  fault  risk  (CFR)  -  A  risk  associated  with  a  potential  fault  or  flaw  that  would  lead  to 
mission  failure. 

Mission  Critical  Fault  Analysis  (MCFA)  -  A  mission  oriented  top-down  analysis  that  focuses 
on  determining  the  events  and  sequences  of  events  that  can  lead  to  mission  failure  in  any 
phase  of  the  mission  up  to  and  including  nominal  operations. 

Operationally  Relevant  Test  (formerly  Test  Like  You  Fly  (TLYF))  -  Any  pre-operational  test 
based  on  operational  timelines,  configurations,  and  other  applicable  mission  characteristics. 

a  As  part  of  System  Requirements  Definition  Activities  and  Tasks,  clause  6.4.3. 3,  the 
contractor  shall  conduct  a  Mission  Critical  Fault  Analysis  (MCFA)  that  includes: 

(1)  List  of  mission  critical  failures  that  can  cause  loss  of  mission  or  inability  to  execute 
mission. 

(2)  For  each  mission  critical  failure,  the  fault  analysis  with  potential  flaw  contributors. 

b.  As  part  of  System  Analysis  Activities  and  Tasks,  clause  6. 4.6. 3,  the  contractor  shall  conduct 
critical  fault  risk  (CFR)  assessments. 

c.  Each  assessment  of  critical  fault  risk  (CFR)  includes  identification  and  documentation  of: 

(1)  All  first-time  events  and  mission  critical  activities  not  allocated  to  operationally 
relevant  tests  as  part  of  program  test  plans. 

(2)  Operationally  relevant  test  exceptions  that  are  correlated  to  the  MCFA. 

d.  As  part  of  System  Analysis  Activities  and  Tasks,  clause  6. 4.6. 3,  and  System  Realization 
Verification  Activities  and  Tasks,  clause  6.4. 9. 3,  the  contractor  shall  conduct  mission  critical 
fault  analysis  (MCFA)  to  identify  the  mission  critical  failures  for  each  mission  phase  and  the 
associated  fault  conditions  with  the  following  attributes: 

(1)  Mission  failures  are  identified  by  a  team  representing  all  mission  elements  and 
technical  disciplines.  Each  potential  mission  failure  will  be  populated  with  all  single 
fault  paths  to  that  failure. 

(2)  Single  fault  paths  include  those  that  involve  mismatches  between  two  items  or 
elements  (e.g.,  race  conditions,  counting  strategy,  or  engineering  units). 

(3)  Each  mission  failure  analysis  will  be  documented  (e.g.,  in  an  analytical  tool  such  as 
master  logic  diagram,  fault  tree,  event  tree,  or  Ishikawa  diagram). 
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(4)  MCFA  will  be  updated  as  necessary  to  reflect  changes  in  operations,  hardware 
design,  or  software  design. 

3.2.19  Operationally  Relevant  Testing 

NOTE:  Operationally  Relevant  Testing  was  formerly  known  as  Test  Like  You  Fly  -  TLYF. 

a.  As  part  of  Stakeholder  Needs  and  Requirements  Definition,  clause  6.4.2,  the  contractor 
shall  participate  with  the  customer,  if  contractually  directed,  in  developing,  refining,  and 
updating  operational  test  and  operationally  relevant  test  planning. 

b.  As  part  of  System  Requirements  Definition,  clause  6.4.3,  Operational  concepts 
documentation  ensures  that  all  mission  operational  data  interactions  and  transactions  are 
validated  in  operationally  relevant  tests. 

c.  As  part  of  Design  Definition,  clause  6.4.5,  the  validated,  approved,  and  maintained 
design  release  baseline  shall  be  validated  through  customer  involvement  to  ensure  that 
operationally  relevant  tests  to  support  design  decisions  are  architected  and  designed  to 
reflect  mission  usage,  including  appropriate  selection  of  mission  characteristics,  and 
critical  fault  risk  assessment  for  deviations  from  mission  characteristics  or  usage. 

d.  As  part  of  Integration,  clause  6.4.8,  the  contractor  shall  allocate  operationally  relevant 
validation  tests  to  appropriate  levels  of  hardware,  software,  and  hardware/software 
integration;  to  appropriate  vendors;  and  to  levels  of  mission  functional  integration.  The 
customer  or  customer  representative  shall  coordinate  multiagency  and/or  multicontractor 
operationally  relevant  integration  test  planning  and  discrepancy  resolution. 

(1)  Assembly/integration  and  verification  procedures  shall  ensure  that: 

a.  Assembly/integration,  verification,  and  operationally  relevant  test  validation  of 
component/software  unit  interfaces  and  mission  functionality/interoperability. 

b.  Assembly/integration,  verification,  and  operationally  relevant  test  validation  of 
hardware/software  item  interfaces  and  mission  functionality/interoperability. 

(2)  Discrepancy  reporting,  causal  analysis,  and  corrective  action  procedures  shall  ensure 
that  discrepancy  reporting,  causal  analysis,  and  corrective  action  procedures  are 
integrated  with  the  assembly  and  verification  procedures  and  operationally  relevant 
test  validation  procedures 

(3)  Operationally  relevant  test  architecture  and  design  plans,  test  procedures,  test 
exceptions  and  associated  fault  risk  assessment,  and  test  results  and  discrepancies 
shall  ensure  that  operationally  relevant  test  information  is  correlated  to  provide 
context  and  significance: 

a.  Each  test  objective  is  mapped  to  mission  phase  objectives,  first -time  events, 
mission-critical  events,  and/or  fault  paths. 

b.  Test-specific  exceptions  are  mapped  to  mission  characteristics  and  MCFA  fault 
paths. 
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c.  Each  test  discrepancy  is  mapped  to  an  identified  test  exception(s)  or  MCFA 
fault  path(s),  where  possible. 


e.  As  part  of  System  Realization  Verification,  clause  6.4.9,  the  contractor  shall  ensure  that 
the: 

(1)  System  Validation  Plan  includes  plans  for  accomplishing  operationally  relevant  test 
assessments,  including  a  mission  readiness  test. 

(2)  System  Validation  Data 

a.  Documents  any  discrepancies  between  the  operationally  relevant  test 
characteristics  and  mission  characteristics. 

b.  Includes  operationally  relevant  test  results,  discrepancies,  and  exceptions. 

f.  As  part  of  Project  Assessment  and  Control,  clause  6.3.2  and  System  Realization 
Verification,  clause  6.4.9,  the  contractor  shall  ensure  that  each  documented  assessment 
includes  the  critical  fault  list  with  the  following  attributes: 

(1)  Includes  critical  fault  risks  associated  with  decisions  to  not  perform  operationally 
relevant  tests  and  with  test  exception  faults  that  cannot  be  mitigated  within  allocated 
resources  for  test/repair/rework/retest. 

(2)  Elevates  to  program  risk  management  any  operationally  relevant  test  necessary  to 
validate  the  executability  of  a  first -time  event,  mission  critical  activity,  or  mission 
sequence  that  cannot  be  performed  within  element  test  resources. 


3.2.20  Space  System  Verification 

a.  A1AA-S- 1 1 7A-20 1 6  may  be  used  for  development  of: 

(1)  space  system  verification  process 

(2)  associated  verification  outputs 

3.2.21  Systems  Engineering  Data  Item  Descriptions 

NOTE:  Address  as  part  of  IEEE  15288.1  clause  6.3.1,  Project  Planning. 


1 .  Systems  Engineering  Management  Plan  (SEMP) 

2.  System/Segment  Interface  Control  Specification 

4.  System/Subsystem  Specification 

5.  Eluman  Systems  Integration  Plan 


D1-SESS-81785A 

DI-SESS-81314A 

DI-1PSC-81431A 

DI-HFAC-81743A 


Data  Item  Descriptions  (DIDs)  are  maintained  in  an  online  database,  Acquisition  Streamlining 
and  Standardization  Information  System  (ASSIST),  maintained  by  the  Defense  Logistics  Agency. 
ASSIST  contains  standardization  documents  and  data  item  descriptions  that  have  been  approved 
or  adopted  for  contractual  application  in  DOD  acquisitions. 
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4.  Applicable  Documents 

The  following  documents  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise 
specified  the  issues  of  these  documents  are  those  cited  in  the  solicitation  or  contract. 

•  1SO/1EC/1EEE-15288:2015,  Systems  and  Software  Engineering  —  System  life  cycle  processes. 
2015. 

•  IEEE-15288. 1:2014,  IEEE  Standard  for  Application  of  Systems  Engineering  on  Defense 
Programs.  2014. 

•  Systems  Engineering  Requirements  and  Products,  Aerospace  Report  Number  TR-20 13-0000 1 . 
The  Aerospace  Corporation,  El  Segundo,  CA.  February  28,  2013. 

also  published  as  SMC-S-001  (2013),  Systems  Engineering  Products  and  Requirements.  2013. 

•  Space  Vehicle  Test  and  Evaluation  Plandbook,  Aerospace  Report  Number  TOR-201 1(859 1)-2 
Volume  1,  Chapter  15:  Test  Like  You  Fly  —  Assessment  and  Implementation  Process  for 
Prelaunch  Mission  Testing.  The  Aerospace  Coiporation,  El  Segundo,  CA.  2012. 

•  Test  Like  You  Fly:  Assessment  and  Implementation  Process.  Aerospace  Report  Number  TOR- 
2010(8591)-6.  The  Aerospace  Coiporation,  El  Segundo,  CA.  2010. 

•  The  Test  Like  You  Fly  Process  Guide  for  Space,  Launch,  and  Ground  Systems.  Aerospace  Report 
Number  TOR-2014-02357-REV  A.  The  Aerospace  Corporation,  El  Segundo,  CA.  2016. 

•  A1AA-S-1 17A-2016,  Space  Systems  Verification  Program  and  Management  Process.  American 
Institute  of  Aeronautics  and  Astronautics  (A1AA).  2016. 
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INSTRUCTIONS 

1.  Complete  blocks  1  through  7.  All  blocks  must  be  completed. 

2.  Send  to  the  Preparing  Activity  specified  in  block  8. 
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SMC  STANDARD 

CHANGE 

RECOMMENDATION: 

1.  Document  Number 

SMC-T-006 

2.  Document  Date 

2017 

3.  Document  Title 

Specialty  and  Software  Engineering  Supplement  to  IEEE  15288.1 

4.  Nature  of  Change 

(Identify  paragraph  number;  include  proposed  revision  language  and  supporting  data.  Attach  extra  sheets  as  needed.) 

5.  Reason  for  Recommendation 

6.  Submitter  Information 

a.  Name 

b.  Organization 

c.  Address 

d.  Telephone 

e.  E-mail  address 

7.  Date  Submitted 

8.  Preparing  Activity 

Space  and  Missile  Systems  Center 

AIR  FORCE  SPACE  COMMAND 

483  N.  Aviation  Blvd. 

El  Segundo,  CA  91245 

Attention:  SMC/EN 

